1. The Field of the Invention
The present invention is directed to clock-slaving in a computing system and, more particularly, to synchronizing the effective rates of different clocks that are used when writing and reading streaming multimedia data in a Programmable Video Recorder (PVR).
2. Related Technology
The PVR, also known as the Digital Video Recorder (DVR), has recently entered the home entertainment market as a device that is capable of providing many conveniences not previously considered practical for the traditional Video Cassette Recorder (VCR). Once particular benefit provided by the PVR is that the PVR is capable of simultaneously recording and playing different data content. In particular, the PVR utilizes a writer that is capable of writing data to a storage medium at the same time a reader accesses and reads the same or different data from the storage medium.
The utility of being able to record and play data at the same time is a significant advantage over the traditional VCR. In particular, the PVR enables the viewer watching a live or broadcast program to temporarily pause, rewind or replay a portion of the recorded program without interrupting the contemporaneous recording of the broadcast. Accordingly, the viewer can later watch the portions of the program that were broadcast and recorded during the temporary pause in the play of the program.
To enable this functionality, the PVR includes a temporary storage buffer that is included within a storage medium. The buffer that is utilized by many PVRs includes a ring buffer that is configured to store a predetermined amount of data. Ring buffers, which are well-known to those of ordinary skill in the art, are configured to sequentially record data until the ring buffer becomes full. Then, once the ring buffer becomes full, the most recently received data is written over the oldest data in a continuous and cyclical manner.
The ring buffer is useful for maintaining a copy of the most recently received data. Accordingly, even if the viewer pauses, slows down, or stops the play of the program, the most recently received data will continue to be written to the buffer for access at a later time. However, if the viewer pauses the program for such a lengthy period of time that the capacity of the buffer is exceeded, then portions of the recorded data that have not yet been rendered will be overwritten and lost, which is typically undesirable.
Even when a viewer is not pausing or stopping the play of the recorded program for an extended period of time, however, the recorded data may still be undesirably overwritten and lost. This may occur, for instance, when the reader continuously reads the data at a slower rate than the data is written to the buffer. This may actually occur without the viewer's knowledge. One reason data may be read at a relatively slower rate than it is recorded is that different clocks associated with the PVR may be set at different speeds or frequencies.
The PVR may be associated with numerous clocks for controlling the rate at which data is received, processed, recorded and rendered. However, only two clocks are specifically addressed herein. A first clock, which is referred herein as a capture graph clock, may be used as a reference for assigning Presentation TimeStamps (PTS)s to the data before the data is written to the buffer. The PTSs that are assigned to the data correspond with an intended presentation playback rate of the recorded data. A second clock, which is referred to herein as a system clock, may be used as a reference for reading and rendering the data with respect to the assigned PTSs.
A description of the relationship between the capture graph clock and the system clock will now be provided with reference to the data sample 110 that is shown in FIG. 1. As a matter of example, data sample 110 includes a plurality of data packets (D1, D2, D3, D4 and D5). Data sample 110 may include audio data, video data, and any other type of multimedia data. Data sample 110 may also include non-multimedia data, such as events, markers, metadata, and so forth. The data packets (D1, D2, D3, D4 and D5) represent portions of the data sample 110 that have been assigned PTSs according to a capture graph clock. For instance, data packet D1 has been assigned a PTS of PTS=1, data packet D2 has been assigned a PTS of PTS=2, and so forth, wherein the increments may correspond with seconds or other units of time.
The data sample 110 may be stored in a ring buffer or any other type of storage medium that is associated with the PVR. When the data sample 110 is read, it will be rendered according to the PTSs that have been assigned to the data packets. For instance, if the PTSs correspond with seconds, then data packet D1 will theoretically be rendered one second after commencing the playback of the data sample, then one second later data packet D2 will be rendered, then one second later data packet D3 will be rendered, and so forth.
However, the actual duration associated with one theoretical second may vary between the capture graph clock and the system clock due to slight variations as described below. Accordingly, even though the capture graph clock may intend for the data packets to be rendered at desired presentation times, the system clock may cause the data packets to be read and rendered at a slower rate if the system clock runs at a slower rate than the capture graph clock.
When the system clock runs at a slower rate than the capture graph clock for an extended period of time, the capacity of the buffer will eventually be exceeded, thereby causing the data to overwritten and lost. In contrast, when the system clock runs faster than the capture graph clock for an extended period of time, the playback rate will eventually exceed the rate in which the data is written to the buffer, thereby causing an underflow problem and a choppy playback.
It is desirable, therefore, to ensure that the capture graph clock and the system clock are running at the same rates. However, even when the capture graph clock and the system clock are programmed to run at the same rate, slight irregularities may still cause the two clocks to run at slightly different rates. This phenomena may be more clearly understood in reference to other types of time-keeping devices. For instance, wristwatches that are synchronized will typically become unsynchronized over an extended period of time, notwithstanding the fact that they are originally configured to run at the same rate (e.g., a 24 hour/day, 60 minute/hour and 60 second/minute). The reason for this is that the watches may have slight variations or irregularities that cause the wristwatches to run at slightly different rates. Variations in the power supply to the watches may also cause them to run at slightly different rates. This is also true of the capture graph clock and the system clock that are associated with the PVR.